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REMARKS 

Reexamination and reconsideration of this application in view of the following remarks is 
respectfully requested. By this amendment, claims 1, 9, 12 and 17 are amended; no claims are 
currently canceled; and new claim 25 is added. After this amendment, claims 1, 2, 3, 9, 10, 11, 
12, 17, 18, 24 and 25 remain pending in this application. 

Claim Rejections - 35 USC §103 

Reconsideration of the rejection of claims 9-12 under 35 U.S.C. §103(a) as being 
unpatentable over Rawson et al, (U.S. Pat. No. 5,692,204), hereinafter "Rawson", in view of 
Balasubramanian (U.S. Pat. No. 6,487,455) is respectfully requested in view of the amendment 
to independent claim 9 and for the following reasons. 

With the Applicants' invention, the operating system software of the electronic device 
accesses resource requirements associated with an application prior to any execution of any code 
of the application. The method in accordance with the Applicants' invention evaluates the 
current state of the electronic device and decides before the application is executed by the 
electronic device, how an application will or will not be executed. 

On the other hand, with Rawson, any resources requirements needed by an application, 
such as power management, is performed only after the application has started, i.e., only after 
some of the code of the application has already executed. Rawson teaches a set of power 
management system calls that may be accessed by either a power management proactive 
application (203) or a Command Script (201). In this way, a script or an application, which is 
already running , is given a way to register its requirements and then to suspend its operation until 
the registered requirements are met. With the Applicants' invention, the resource requirements 
(which may include power management requirements) are attached in a Java Descriptor file as 
metadata to an application, so that the operating system may examine the requirements before 
any portion of the application starts to run. 

Claim 9 was amended to specifically recite that the metadata is in a form of a Java 
Descriptor file . The following excerpts from the Applicants' specification teach placing the 
resource requirements of an application in a Java Descriptor file (J AD) associated with the 
application. See page 12, line 16 to page 14, line 14 of the Applicants' specification, as follows: 
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"In one embodiment of the present invention, an application resource requirement (ARR) file 352 
associated with the application 350 can also be stored in the storage module 310. ARR file 352 includes 
data related to the application resource requirements associated with the execution of the application 350 
on the wireless device 106. A more detailed description of application resource requirements is provided 
below. ARR file 352 can be a Java Descriptor file (JAP) or other file typically used for holding 
metadata pertaining to another file and be stored as part of the file or in a resource directory such as a bat, 
dat, registry, or other resource file. An exemplary JAP file including power management and 
performance application resource requirements is shown below. 

MIDlet-1: AsteroidsGame, 

AsteroidsGame.png, 

com. mot.j2me. midlets.AsteroidsGame 

MIDlet- Jar-Size: 134859 
MIDlet-Jar- URL: AsteroidsGame. jar 
MIDlet-Name: AsteroidsGame 
MIDlet-Vendor: Motorola, Inc. 
MIDlet-Version: 85.00.16 
SMTPServer: idenmoto.com 

iDEN-MIDlet-Performance-FPS-TARGET: 12 // 12 Frames/Second IDEAL 
iDEN-MIDlet-Performance-MIPS-A VG: 5 // Average 5 MIPS 

iDEN-MIDlet-Performance-MIPS_MIN: 3 // Need at least 3 MIPS to Run 

iDEN-MIDlet-Performance-MIPS_BACKG: 0. 3 // Need at least 0. 3 MIPS 



MIDlet- 1: MP3AUDIOPlayer, MP3AUDIOPlayer.png, 

com. mot.j2me. midlets.MP3A UDIOPlayer 

MIDlet- Jar-Size: 234200 

MIDlet-Jar- URL: MP 3 A UDIOPlayer. jar 

MIDlet-Name: MP3AUDIOPlayer 

MIDlet-Vendor: Motorola, Inc. 



// to Run when used in 



iDEN-MIDlet-Performance-CIass: None 
iDEN-MIDlet-Performance-IO: None 



// Background mode. 
//Not performance critical App 
//No a factor for this App 
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MIDlet- Version: 85. 00. 1 1 
SMTPServer: idenmoto.com 

iDEN-MIDlet-Performance-FPS-TARGET: 15 // 12 Frames/Second iDEAL 
iDEN-MIDlet-Performance-MIPS-AVG: 50 //Average 50 MIPS 
iDEN-MIDlet-Performance-MIPS_MIN: 35 //Need at least 35 MIPS to Run 
iDEN-MIDlet-Performance-MIPS_BACKG: 10 //Need 10 MIPS when placed on 

//Background Mode 

iDEN-MIDlet-Performance-Class: Medium //Relative Performance App 
iDEN-MIDlet-Performance-IO_SDIO: 44kb //Need BW 'from SDIO port" [Emphasis added] 

Therefore, because the Applicants' invention uses metadata in a Java Descriptor file that 
is embedded in an application, the application does not have to first execute for the operating 
system to determine the resource requirements of the application. With the Applications' 
invention, the resource requirements of an application can be determined prior to the application 
running. With the Applications' invention, the resource requirements of an application can be 
determined without the application ever running (not even once). This is in contrast with 
Rawson, which requires each application to execute its application code, wherein the application 
code of Rawson makes system calls to provide resource requirements to the operating system. 

Neither Rawson nor Balasubramanian discloses metadata in a form of a Java Descriptor 
file . The combination cited by the Examiner fails to disclose all the steps of amended claim 9. 
In particular, combination cited by the Examiner fails to disclose the second step of amended 
claim 9, to wit: 

"prior to any execution of any code associated with the application, reading 
an application priority level application resource requirement of the application 
stored in metadata associated with the application, in which the application priority 
level application resource requirement indicates how important it is for the single 
processor to execute the application in the regular performance mode, and in which 
the metadata is in a form of a Java Descriptor file;" 

The change to second step of amended claim 9 is supported by the specification, including, for 
example, at page 15, lines 12-16 (which was reproduced above). No new matter was added. 
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Furthermore, combination cited by the Examiner fails to disclose the last step of amended 
claim 9, to wit: 

"if the application priority level application resource requirement associated 
with the application includes a high priority level, then preventing the execution of 
other low priority applications on the single processor of the electronic device while 
the application that has a high priority level is being executed." 

The newly added last step of amended claim 9 is supported by the specification, including, for 
example, at page 19, lines 13-24. No new matter was added. 

The Applicants agree with the Examiner that Rawson does not teach that the application 
resource requirement of the application is stored in metadata associated with the application. 
Also, the Applicants agree with the Examiner that Rawson does not teach that resource 
requirements are declared by a software developer. 

The Examiner also cited the following portion of Balasubramanian in support of the 
rejection of claim 9: 

At prr>i\-s* block 56 die operating sysk-m c»<le 4K checks 
ihii-hi 'iJt-l'w vji i h hp n 40 — , K vl i , v, m t 
the ppM ion ( „[ i i ids i i on til sac a 
psiiji red iik «1 lh« high fevd rcqi tram* iJs40oi m*> so Iks & 
the piOH.i aiitt.nei' to i«piti the ix:c^;iry mibmmkffi about the 
lnj> ivvhai ii .nl 40 In i 1 1 m i v i ii' nil < 
like, or may be s^msmsUnnauc iavoMng s ft view of fbe 

tpp i 1 11M. C Ull 34] '1 is I x n] h I m csci d.> jik] 
lhx. IA \v sli ^ n dii 1 dv^i kJ il> p . Lsp i i 1ft 

4, principally Ibyr bighkeved recpjircmenls arc amkn'paieok 
that of hardware requirements, com pletion-iisxmg 
c*:T:>t: mt.s ncsssgc st/i.-s i d l t f.Ht rm i • i y I 
O h>g cvd .rctpiii tm are \ dbk i ] i I > i > 

ML IVII1 U 111 V VJL^- L I ' ] p < l 11' 

iippSiviiliOEi, etc. 

The Applicants disagree with the Examiner that the use of a prepared file of requirements 
by Balasubramanian is related to the Applicants' invention. Balasubramanian discloses a 
distributed control system that includes multiple nodes 12a, 12b and 12c. Each node has its own 
processor 26a, 26b and 26c, respectively. The nodes have inputs and outputs A, B, C and D. 
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The distributed control system of Balasubramanian is pictured in FIG. 4 thereof, where multiple 
processors are clearly indicated. Therefore, the operating system of Balasubramanian is 
applicable only to a distributed control system that has multiple processors. 

The "high-level requirements 40" referred to in the above portion of Balasubramanian 
that was cited by the Examiner are described more fully elsewhere in Balasubramanian. See for 
example, col. 5, line 43 to col. 6, line 21, where it is explained that the "high-level requirements 
40" relate to how the multiple nodes (each node having a processor) of Balasubramanian work 
together. Therefore, the "high-level requirements 40" of Balasubramanian are requirements 
related to multiple processors. Such "high-level requirements 40" of Balasubramanian are 
unrelated to the Applicants' invention because the Applicants' electronic device comprises a 
single processor, as recited in amended claim 9. Therefore, amended claim 9 should be allowed. 

Referring now specifically to the rejection of claims 10-12. Claims 10-12 depend upon 
independent claim 9, and because dependent claims recite all the limitations of the independent 
claim, it is believed, for at least this reason, that dependent claims 10-12 also recite in allowable 
form. 

Accordingly, the Applicants believe that the rejection of claims 9-12 under 35 U.S.C. 
§ 103(a) as being unpatentable over Rawson in view of Balasubramanian has been overcome. 
The Examiner should withdraw the rejection of claims 9-12. 

Reconsideration of the rejection of claims 1-3, 17-18 and 24 under 35 U.S.C. § 103(a) as 
being unpatentable over Rawson in view of Balasubramanian, in view of Guzzi et al., (U.S. Pat. 
Pub. No. US200 1/0049847 Al), hereinafter "Guzzi", and further in view of Diepstraten et al, 
(U.S. Pat. No. 6,243,736), hereinafter "Diepstraten", is respectfully requested in view of the 
amendments to claim 1 and independent claim 17, and for the following reasons. Claims 1 and 
17 were amended to more clearly recite the Applicants' invention. No new matter was added. 

Referring now specifically to the rejection of claim 1 . Neither Rawson, 
Balasubramanian, Guzzi, nor Diepstraten discloses metadata in a form of a Java 
Descriptor file, as recited in amended claim 1, and as discussed hereinabove with respect 
to the rejection of claim 9. 

Referring now specifically to the rejection of claim 17. Claim 17 has been amended to 
distinguish over the combination of references cited by the Examiner. The combination cited by 
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the Examiner fails to disclose all the steps of amended claim 17. In particular, the combination 
fails to disclose the following steps of amended claim 17: 

"a secure digital input/output (I/O) slot for receiving a MPEG4 video clip from a 
secure digital I/O card; 

a display, for indicating to the user that the MPEG4 video clip cannot be executed 
on the electronic device without performance of the MPEG4 video clip being adversely 
affected, for indicating to the user that the I/O bandwidth application resource requirement 
cannot be met by the electronic device, for indicating to the user how the electronic device 
can be modified to meet the I/O bandwidth application resource requirement, and for 
prompting the user for agreement to modify the electronic device, in which the user 
interface receives a command indicating that the user agrees to a modification of the 
electronic device to meet the I/O bandwidth application resource requirement of the 
application, in which the processor modifies the electronic device, and in which, 
subsequent to modifying the electronic device, the processor executes the MPEG4 video 
clip on the electronic device." 

The changes to amended claim 17 are supported by the specification, including, for 
example, at page 19, lines 13-24, which is reproduced below for the Examiner's convenience: 

"The I/O bandwidth application resource requirement indicates the amount of 
bandwidth that is necessary in the file system, the network connection, a peripheral or 
system memory of the electronic device that is required for execution of the application 
350. In this embodiment, the application 350 is used to determine if enough resources 
are available on the electronic device. For example, assume that the user is playing 
an MPEG4 video clip with MP3 audio from a Secure Digital I/O (SDIO) slot and the 
user tries to execute an application 350 that requires access to the SDIO card to read 
data. Then, if there is not enough bandwidth available to run both applications, the 
present invention should alert the user of the problem rather than affecting the 
performance of the MPEG4 video clip. Furthermore if the priority level of the MPEG4 
player is high, then low priority applications will not be allowed to run." 
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The Applicants agree with the Examiner's statement, "Rawson does not teach indicating to 
a user that the application cannot be executed on the electronic device, indicating to the user which 
application resource requirement cannot be met by the electronic device, indicating to the user how 
the electronic device can be modified to meet the application resource requirement, prompting the 
user for agreement to modify the electronic device, in response to a command indicating 
agreement, modifying the electronic device to meet the application resource requirement 
associated with the application, and executing the application on the electronic device". 

However, the Applicants disagree with the Examiner that the recommendations made by 
Guzzi are similar to the way the Applicants' electronic device operates. Furthermore, neither 
Rawson, Balasubramanian, Guzzi nor Diepstraten discloses an electronic device having a secure 
digital input/output (I/O) slot for receiving a MPEG4 video clip from a secure digital I/O card, as 
recited in amended claim 17. 

Referring now specifically to the rejection of claims 2, 3, 18 and 24. Claims 2-3 depend 
upon independent claim 1, and claims 18 and 24 depend upon independent claim 17, and because 
dependent claims recite all the limitations of the independent claim, it is believed, for at least this 
reason, that dependent claims 2, 3, 18 and 24 also recite in allowable form. 

Therefore, the Applicants believe that the rejection of claims 1-3, 17-18 and 24 under 35 
U.S.C. § 103(a) as being unpatentable over Rawson in view of Balasubramanian, in view of 
Guzzi, and further in view of Diepstraten, has been overcome. The Examiner should withdraw 
the rejection of claims 1-3, 17-18 and 24. 

Conclusion 

The foregoing is submitted as full and complete response to the Office Action dated 
January 22, 2009. It is believed that the application is now in condition for allowance. 
Allowance of claims 1, 2, 3, 9, 10, 1 1, 12, 17, 18, 24 and 25 is respectfully requested. 

No amendment made was related to the statutory requirements of patentability unless 
expressly stated herein. No amendment made was for the purpose of narrowing the scope of any 
claim, unless the Applicants have argued herein that such amendment was made to distinguish 
over a particular reference or combination of references. 
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The Applicants acknowledge the continuing duty of candor and good faith in the 
disclosure of information known to be material to the examination of this application. In 
accordance with 37 CFR §1.56, all such information is dutifully made of record. The foreseeable 
equivalents of any territory surrendered by amendment is limited to the territory taught by the 
information of record. No other territory afforded by the doctrine of equivalents is knowingly 
surrendered and everything else is unforeseeable at the time of this amendment by the Applicants 
and their attorneys. 

The Commissioner is hereby authorized to charge any fees that may be required or credit 
any overpayment to Deposit Account No.: 50-1556. 

PLEASE CALL the undersigned attorney at (561) 989-981 1, should the Examiner 
believe a telephone interview would help advance prosecution of the application. 

Respectfully submitted, 

Date: April 22, 2009 By: /Jon Gibbons/ 

Jon A. Gibbons, Reg. No. 37,333 
Attorney for Applicants 



FLEIT, GIBBONS, GUTMAN, 
BONGINI & BIANCO P.L. 
551 N.W. 77th Street, Suite 111 
Boca Raton, FL 33487-1330 
Tel (561) 989-9811 
Fax (561) 989-9812 
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